The present invention relates generally to computer systems for simulating the operation of electronic circuits, software, mechanical systems, hydraulics, pneumatics, electromechanical systems, and combinations thereof, particularly to a system and method for integrating the operation of simulation objects representing various portions of a heterogenous system.
A cosimulation is defined to mean the coordinated simulation, using N simulators, of N sub-models that together form a comprehensive model of a corresponding comprehensive system, in a way that the cosimulation behaves as closely as possible to one hypothetical simulation of the comprehensive model by one hypothetical simulator capable of simulating the comprehensive system.
The development of complex systems is almost always an interdisciplinary task involving several development teams that work on various components of the system in parallel. An example is the development of the electronically controlled transmission in a car: while one team might be concerned with increased fuel economy by improving the software implementing complex, potentially adaptive control algorithms, another team might investigate the ramifications of replacing an electronic sensor by a cheaper product, and a third might be working on the mechanical or hydraulic components of the transmission.
Any detailed simulation of the transmission""s operation logic needs to include not only models of the mechanical and hydraulic components, but also electromechanical models of the sensors and actuators, and a model of the electronic control unit that implements the control logic. These different components will likely have been developed in different groups using different software tools, for example:
a tool for modeling and simulating abstract dynamic systems and designing embedded control software (such as MATRIXx, a product of Integrated Systems, Inc.),
a tool for modeling and simulating the mechanical aspects of the transmission,
a tool for modeling and simulating the electronic circuitry in the transmission, and
a tool for modeling and simulating the hydraulic components of the transmission.
Two fundamental approaches are possible when attempting to simulate such a heterogeneous system: either, one simulator is used that is able to simulate the entire comprehensive system, or a number of simulators is used in a coordinated manner so that the collective simulation results reflect the behavior of the transmission as a whole. The latter approach is called cosimulation.
Neither standard data formats that could represent a system as heterogeneous as the one in this example nor simulation tools that could simulate it exist today. Such simulation tools are not expected to exist in the foreseeable future. Thus a system simulation of a heterogeneous system requires a cosimulation of N simulators with different capabilities. Preferably the cosimulation will be between the simulators of all the tools that have been used when developing the components.
In order to allow this cosimulation of N simulators from different vendors, simulating models using different modeling paradigms (e.g., electronics, software, mechanics, etc.) and with various simulation methods (e.g., event-queue-based, differential equation based, etc.) without significant restrictions, a sophisticated cosimulation architecture is necessary.
Several cosimulation approaches have been proposed and implemented, partially as commercial products, in the past. See L. Maliniak, xe2x80x9cBackplanes Mesh Simulators into One Environment,xe2x80x9d Electronic Design (Aug. 8, 1994); and S. Schmerler et al., xe2x80x9cA Backplane for Mixed-Mode Cosimulation,xe2x80x9d in Proc. Eurosim 1995, Vienna, Austria. They range from ad-hoc integrations of two simulators, to complex simulation backplanes. Depending on the specific approach or product, various problems have effectively prevented their wide-spread adoption. In particular, it has been difficult to extend the prior art cosimulation techniques to cosimulations having multiple simulators using different simulation techniques (such as multiple differential equation solvers) and to incorporate extensions such as new data types.
The present invention avoids problems associated with prior cosimulation techniques. In particular it:
Uses a standardized protocol for exchanging signals between simulation objects, rather than a proprietary one. This makes it easier to ntegrate simulation products from different companies.
Can handle a virtually unlimited number of simulators operating together.
Does not require the use of a fixed set of synchronization techniques to synchronize the operations of the cosimulating simulators. In fact, multiple synchronization methods can be used concurrently in different parts of the cosimulation.
Can be used on one CPU, or across networks on different platforms.
Allows parallel execution of simulations.
Is not limited with respect to the simulation methods that participating simulators may use. Thus the cosimulation is not limited to discrete-event simulations only. Also there is no limit on the number of differential equation solvers used.
The numerical precision of the cosimulation degrades gracefully if some of the participating simulators do not support the full cosimulation protocol, in particular rollback capabilities. This allows virtually any simulator to participate in a cosimulation, albeit with less than ideal precision in some circumstances, in spite of not having rollback capabilities.
Cosimulation, according to the definition given above, should be part of a comprehensive development process whose goal is to create one comprehensive system, rather than different, non-integrated models for various components. The comprehensive model may be arbitrarily heterogeneous. In particular, its sub-models may use a wide variety of modeling languages and techniques, and may use a wide variety of simulation techniques.
Most previous cosimulation approaches have advocated a bus-line or star-like structure for cosimulation. An example of the star structure, also known as the backplane structure, is shown in FIG. 1. In the backplane type of cosimulation system, the backplane controls the simulation time steps used by all simulators, and essentially tells all the simulators when to perform each incremental simulation step (i.e., when all the simulators are ready to perform that next step). In backplane based cosimulation systems, there are no parent/child relationships between simulators; all simulators are equal xe2x80x9csiblingsxe2x80x9d that simply share signal values with each other. All the simulators run independently of each other, synchronized by signals generated by the backplane. There are several problems with the backplane cosimulation structure. For instance, like most centralized systems, it does not scale up well. When the number of simulators increases, the number of interactions between simulators increases, and the backplane becomes a bottleneck. The bottleneck problem can be solved by using a peer-to-peer setup, using a virtual object bus, as shown in FIG. 2. However, this cosimulation structure is, in general, entirely unrelated to the structure of the comprehensive model. It also violates the abstract design principles of encapsulation and locality. Thus, like the backplane based cosimulation structure, the peer-to-peer structure also treats all simulators as equal, parallel partners in the simulation, all running independently except for periodic data exchanges.
Many traditional approaches to cosimulation, including the backplane and peer-to-peer structures mentioned above, assume that the comprehensive model has a flat structure, such as the one shown in FIG. 3. In a flat structure, all simulators are equal partners in the cosimulation. No simulator can invoke another simulator in order to generate its results. For this reason, each component of the system must be modeled using only one tool, and the system being simulated must be partitioned in terms of simulation tools, rather than in terms of functions. Also, in violation of real time system analysis principles, a flat cosimulation structure must support point-to-point communication from virtually all outputs of a simulator to all inputs of all other simulators.
While the flat structure might be appropriate for small models, it is inappropriate for larger models. Larger models will almost always be hierarchical, and will often be heterogeneous in any branch of the hierarchy. In other words, individual branches of the hierarchy will often require simulations by two or more distinct types of simulators. Also, larger models may contain multiple sub-models creating using the same tool, but in different places in the system hierarchy.
The present invention is a cosimulation system formed from a hierarchy of simulation objects. Each simulation object, other than the root object, is coupled to a respective parent simulation object by a respective, individual parent-child binding that is distinct and separate from every other parent-child binding. As a result, synchronization of simulation objects is handled on an individual parent-child basis, rather than a global basis.
Each of the simulation objects has an interface for communicating with each of its children simulation objects as well as its parent simulation object (if any). The simulation object communication interfaces all use the same, predefined protocol, and send messages to each other via a common protocol communications medium.
Each simulation object includes a simulation module for performing an incremental simulation of a respective subsystem in accordance with a set of associated input signal values. Each parent-child binding defines a source in the respective parent simulation object for each input signal associated with the respective child simulation object, and also specifies a destination in the parent simulation object for each output signal generated by the child simulation object. A predefined set of return data (including the child output signal values) is sent by the child simulation to its parent whenever simulation of the child subsystem is stopped or completed.
Some of the simulation objects include a respective watchdog module for stopping simulation of the respective subsystem whenever a specified condition on a specified input or output signal is satisfied. When one or more watchdog conditions are set on the outputs of a child simulation object, execution of the simulation by the child simulation object is stopped at the earlier of (A) the simulation end time specified by the parent simulation object, and (B) when the respective watchdog condition on any respective output signal of the child simulation object is satisfied. The data returned by the child simulation object includes the actual simulation time at which the execution of the simulation in the child simulation object stopped.
Further, a child simulation object may request from its parent simulation object one or more watchdog conditions to be set on its input signals, which are generated by the parent simulation object. When executing a simulation in the parent simulation object, and the respective watchdog condition on any input signal of the child simulation object is satisfied, execution of the parent simulation is stopped. The time at which the parent simulation is stopped by satisfaction of a watchdog condition is called a breakpoint simulation time. The parent simulation object sends a simulation request to the child simulation object that specified the satisfied watchdog, with the simulation end time being set to the breakpoint simulation time. The watchdog mechanism allows a child simulation object to be synchronized with important signal value changes in the parent simulation object, and vice versa.